Fix required levels for corrupted crafted items - #10302
Open
AdamZ-8113 wants to merge 1 commit into
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes # Couldn't find an issue for this
Description of the problem being solved:
When you apply a corruption to an item through the Craft of Edit item workflows, the required level of the item doesn't get updated based on the corrupted implicit.
The fix retains the selected modifier ID using PoB’s existing item metadata. It calculates the required level from the base, crafted affixes, and corrupted implicits using the existing 80% modifier-level rule. It only applies when the user corrupts an item through the Items tab. Imported and pasted items do not get recalculated (I'm trusting that data to be accurate and it allows a user to manually edit the item if desired).
Four regression tests cover the calculation, conservative behavior, metadata persistence, and later affix changes.
Steps taken to verify a working solution:
Link to a build that showcases this PR:
Before screenshot:
After screenshot: